feat(analyzer): opt-in TRUST_INTURN_RECOVERY flag for hook-retry denials - #348

Problem

should_exit_gracefully halts the next loop when the previous transcript's permission_denials array is non-empty. This is a false positive when a PreToolUse hook denies a Write/Edit tool call with a corrective message and Claude retries the tool call successfully within the same turn — the turn ends with is_error: false and stop_reason: end_turn, work completes, but the next loop halts on permission_denied anyway. Issue #243's exception only covers Bash compound-command denials; hook denials on file-mutation tools have no equivalent carve-out.

Repro

1. Configure a project-level PreToolUse hook that denies Write / Edit when the input matches some rule (e.g. a style hook that rewrites tool_input and returns a corrective deny decision).
2. Run ralph on a task that produces a matching Write/Edit.
3. Claude receives the deny + correction, retries with the fix, succeeds. Turn ends cleanly (is_error: false, stop_reason: end_turn).
4. On the next loop iteration, should_exit_gracefully halts with Permission denied for N command(s): Write, Edit ... Update ALLOWED_TOOLS in .ralphrc, even though nothing is actually blocked and the previous loop's work already landed.

Observed 3 times in one session on this exact pattern.

Fix (opt-in, off by default)

Following the guidance in #264's closing comment — that a broader denial-recovery fix "would be welcome" but "gated behind a config flag, so the default keeps the strict #101 halt" — this PR adds an opt-in TRUST_INTURN_RECOVERY flag (default false) to .ralphrc/templates/ralphrc.template. When true, and every denial in a completed turn is for Write / Edit / NotebookEdit / MultiEdit AND the CLI reports is_error: false + stop_reason: end_turn, should_exit_gracefully logs an advisory and continues instead of halting. Structurally parallel to the Issue #243 compound-command exception (#268).

Default behavior (flag unset or false) is unchanged. All 1007 pre-existing unit tests pass (2 unrelated test_sandbox_e2b.bats failures reproduce on a clean checkout of main too — local Python environment issue on my machine, not caused by this change).

Residual limitation (documented in the ralphrc template with a WARNING: comment, matching the existing CB_AUTO_RESET convention)

is_error: false and stop_reason: end_turn are outcome signals ("the turn didn't crash after the denial") not authorization signals ("the specific denied call was resolved"). A hook that denies a Write to a sensitive path (e.g. .ralphrc itself) which the agent then abandons and moves past would also produce a clean turn end. Enabling TRUST_INTURN_RECOVERY weakens the Issue #101 silent-loop guard for this class of case, which is why it defaults to false and requires explicit opt-in.

Stronger signals (walking assistant messages for a subsequent successful tool_use of the same tool with matching input) were considered and left out to keep this PR minimally scoped, consistent with #268's surgical style.

Verification

• tests/unit/test_hook_retry_recovery.bats (new, 9 tests): flag gating (unset/false/true), coverage of all four file-mutation tools, is_error: true still halts, Bash denials stay out of scope, mixed denials still halt, and two end-to-end tests that exercise the full analyze_response path (not just parse_json_response) to confirm the new fields actually propagate into the .response_analysis file that should_exit_gracefully reads from .analysis.* — parse_json_response's result is re-extracted and re-packaged inside analyze_response, so a wiring gap there would otherwise pass the parse-level tests while still no-op'ing in production.
• tests/unit/test_compound_command_detection.bats (existing, 27 tests): all pass unchanged, confirming the Issue Permission denied but already configured in ALLOWED_TOOLS #243 path is untouched.
• Full tests/unit/*.bats suite: 1007/1009 pass; the 2 failures are pre-existing and unrelated (see above).

References

• Follows the opt-in-flag approach suggested in fix(loop): trust agent RALPH_STATUS before halting on permission denials #264's closing comment, after that PR's broader agent-self-report design was closed in favor of fix(analyzer): treat compound-command denials as non-fatal advisory (#243) #268's narrower one.
• Structurally parallel to fix(analyzer): treat compound-command denials as non-fatal advisory (#243) #268 (Issue Permission denied but already configured in ALLOWED_TOOLS #243 compound-command exception).
• Refines Issue No Approval Request, silent fail #101 / feat(exit): detect permission denials and halt loop (Issue #101) #142 behavior for a narrow, opt-in case only.